In the last section, we added the ability to select an item and the action of double clicking to open
that item for reading, which at the moment simply logs out that you are able to open.
So to add the logic for our new open function.
Let's switch back to item this here where we can now, instead of locking the item, you are allowed
to launch a new window in which to load the item.
You are all we can, of course, do this a number of ways, but the easiest for our purpose is going
to be using a proxy browser window, a concept we've covered earlier in the course, using the window
open function to automatically create and reference a new browser window, a sign that window reference
to reader when creating the window with the item URL by calling window dot open content neutral or leave
the window title empty as that will default to the title from the content neutral.
Save this.
Opened the first item as before by double clicking and we get that window with the item, you are loaded,
essentially completing the ability to read saved items from our app.
That said, we still have a number of issues and possible improvements here.
First of all, the window is being created at the default window size with its X and Y coordinates at
the same point as the main window.
So we can style that.
And secondly, as the main window was responsible for creating this Reider window, all of the reader
window settings gets inherited from that main window, including node integration, meaning we're now
loading remote content into this window with full access to node and essentially our file system.
Same thing for minimum and maximum width and height, although this window was created at the default
size.
So when our resize it snaps to the same size limit as the main window.
Not ideal for reading.
So let's fix all of this with some custom settings on the proxy window.
If you recall from the browser window proxy lesson, we can pass any of the standard browser window
options in string format, along with a few variations such as the node integration setting.
I'll use tactics for a template, literal string, just so I can write this across multiple lines for
legibility.
Start with those window dimensions, max width equal 2000.
This being purely to overwrite the inherited setting from the main window, any large number will do
the same for max height 2000 initial width can be 1200 and height 800 with a slightly off white window
background color D then the all important node integration.
Remember this is enabled in the window responsible for opening this Reider window here.
So disable it by setting node integration with a capital I zero.
We don't use false in string form, but rather one or zero for true and false and for good measure.
Also set context isolation to one or true meaning this Windows JavaScript is executed in its own isolated
context without access to any other JavaScript like that of our main window.
The default here would have been true anyway, as that's the default value on main window.
But better to set it anyway.
Just safeguards Aribert in case the main window settings change.
Save this to test again.
And they're a much better sized window with that or white background also being secured now.
OK, so having this item open in its own window is great and we can close this once we're done with
it by simply closing the window.
But let's say we want to add our own controls to this window for not only closing it when we're done,
but also deleting the item at the same time back in the open function.
Immediately after creating this window, we can inject some of our own JavaScript to add what we need,
calling on the reader when proxy window eval with a string of JavaScript, for example.
Alert hello from items dot James.
Open an item.
And as soon as the content loads, we get that alert right in the remote content, so knowing this,
let's create a button for handling the closing and removing of the open item.
This is, of course, going to be too much JavaScript to write directly into the string.
So instead I'll add it to a separate file and load the content of that file into the eval method.
Call it reader James.
To which we can assign the JavaScript we want to evaluate as soon as the uploads and requires this item
stodginess file.
I'll create that file to hold the reader window JavaScript in Renderer Reader Database Test using an
alert again.
Hello from reader James.
This time back in items doges to find that reader JS variable to which we now want to assign the content
of reader doges not required as a module or anything, simply read its contents so we can pass it to
Evl as a string.
I'll use the FS module to read the file content for start read file.
Require efface.
Const aifs equals require aifs passing the read file function, the path to the file Dearne name being
this renderer directory as both files is in the same directory slash reader database, a callback in
which we can use the file contents providing us an error object should anything go wrong.
And the data or content.
Assigning to that religious variable, DataDot to string as read file returns a buffer by default.
OK, so as soon as the uploads, the main window gets created.
That in turn requires this file item stages where we read the content of Reader's Digest and assign
it to reader.
Is the variable ready for injection once an item is opened here?
Save both files.
Open GitHub dot com again.
And that works as before, except that we can now write JavaScript for this window in a completely separate
JavaScript file in the next lesson, then we'll continue in that new file by creating a button in the
reader window to both close and delete an item once we are done with it.